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Disclosure to Promote the Right To Information 

Whereas the Parliament of India has set out to provide a practical regime of right to 
information for citizens to secure access to information under the control of public authorities, 
in order to promote transparency and accountability in the working of every public authority, 
and whereas the attached publication of the Bureau of Indian Standards is of particular interest 
to the public, particularly disadvantaged communities and those engaged in the pursuit of 
education and knowledge, the attached public safety standard is made available to promote the 
timely dissemination of this information in an accurate manner to the public. 
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NATIONAL FOREWORD 

This Indian Standard which is identical with ISO 17933 : 2000 'GEDI — Generic Electronic Document 
Interchange' issued by the International Organization for Standardization ( ISO ) was adopted by the 
Bureau of Indian Standards on the recommendations of the Documentation and Information Sectional 
Committee and approval of the Management and Systems Division Council. 

The text of the ISO Standard has been approved as suitable for publication as an Indian Standard 
without deviations. Certain conventions are, however, not identical to those used in Indian Standards. 
Attention is particularly drawn to the following: 

Wherever the words 'International Standard' appear referring to this standard, they should be read 
as 'Indian Standard'. 

In the adopted standard, normative references appear to International Standards for which Indian 
Standards also exist. The corresponding Indian Standards which are to be substituted in their place 
are listed below along with their degree of equivalence for the editions indicated: 

International Standard Corresponding Indian Standard Degree of Equivalence 

ISO 2108: 1992 IS 8310 : 2003/ISO 2108 : 1992 Information Identical 

and documentation — International standard 
book numbering ( ISBN ) 

ISO 31 66-1 : 1 997 IS 14836 ( Part 1 ) : 2000/ISO 3166-1 : 1997 Codes do 

for representation of names of countries and 
their subdivisions : Part 1 Country codes 

ISO 3297 : 1 998 IS 1 01 01 : 2003/ISO 3297 : 1 998 Information do 

and documentation — International standard 
serial number ( ISSN ) 

ISO 8601 : 1988 IS 7900 : 1999/ISO 8601 : 1988 Data elements do 

and interchange formats — Information 
interchange — Representation of dates and times 

In the adopted standard, normative reference has been made to ISO 8601 : 1 988 'Data elements and 
interchange formats — Information interchange — Representation of dates and times'. This standard 
has been superseded by ISO 8601 : 2000 for which an identical Indian Standard IS 7900 : 2000 exists. 

In the adopted standard, normative reference has also been made to following International 
Standards for which there are no Indian Standards: 

International Standard Title 

ISO 10161-1 : 1 997 Information and documentation — Open Systems Interconnection — Interlibrary 

Loan Application Protocol Specification — Part 1 ; Protocol specification 

ISO 10161-2:1 997 Information and documentation — Open Systems Interconnection — Interlibrary 

Loan Application Protocol Specification — Part 2 : Protocol implementation 
conformance statement ( PICS ) proforma 
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Indian Standard 

GEDI — GENERIC ELECTRONIC DOCUMENT 

INTERCHANGE 



1 Scope 

This International Standard specifies a format for exchange of electronic document copies between computer 
systems. The format includes the definition of a GEDI Header containing information about the requester, Supplier, 
and format of the document and relevant bibliographic information. 

This International Standard is applicable to computer systems supporting Interlibrary Loan and Document 
Transmission applications. 

2 Normative references 

The following normative documents contain provisions which, through reference in this text, constitute provisions of 
this International Standard. For dated references, subsequent amendments to, or revisions of, any of these 
publications do not apply. However, parties to agreements based on this International Standard are encouraged to 
investigate the possibility of applying the most recent editions of the normative documents indicated below. For 
undated references, the latest edition of the normative document referred to applies. Members of ISO and lEC 
maintain registers of currently valid International Standards. 

ISO 21 08: 1 992, Information and documentation — Intemational standard book numbering (ISBN). 

ISO 3166-1:1997, Codes for the representation of names of countries and their subdivisions — Part 1: Country 
codes. 

ISO 3297: 1 998, Information and documentation — International standard serial number (ISSN). 

ISO 8601 :1 988, Data elements and interchange formats — Information interchange — Representation of dates and 
times. 

150 10161-1:1997, Information and documentation — Open Systems Interconnection — Interlibrary Loan 
Application Protocol Specification — Part 1: Protocol specification. 

IS0 10161-2:1997, Information and documentation — Open Systems Interconnection — Interlibrary Loan 
Application Protocol Specification — Part 2: Protocol implementation conformance statement (PICS) proforma. 

RFC 959, File Transfer Protocol (FTP), October 1985. 

3 Terms and definitions 

For the purposes of this International Standard, the following terms and definitions apply. 

3.1 
consumer 

application process that receives the GEDI record, processes the GEDI Header information, and makes one 
Electronic Document Copy available to the end user 
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3.2 
domain 

group of one or more Suppliers and one or more Consumers capable of engaging in Electronic Document 
Interchange Transactions tjetween tfiem, where a common agreement exists for 1) electronic document 
interchange fomnat and compression algorithm, 2) electronic document transfer mechanism, and 3) network 
technology 

3.3 

Electronic Document Copy 

the part of the GEDI Record that contains the electronic copy of the document 

3.4 

Electronic Document Interchange Transaction 

complete cycle for the interchange of an Electronic Document Copy, starting with an electronic document residing 
at the Supplier and terminating with the completed delivery of that document to the Consumer 

3.5 

GEDI Domain 

Domain in which the common agreements conform to this International Standard 

3.6 

GEDI Header 

GEDI Cover 

the first part of the GEDI Record containing information about 1) the format and version of the parts of the GEDI 
Record, 2) Electronic Document Exchange Transaction, 3) the bibliographic description of the electronic document, 
and 4) the format of the Electronic Document Copy 

3.7 

GEDI Record 

complete GEDI message, containing both the GEDI Header and Electronic Document Copy 

3.8 
Relay 

application process that receives a GEDI Record from a Supplier or Relay in one Domain and transmits it to 
another Relay or Consumer in a second Domain 

3.9 
Supplier 

application process that captures an Electronic Document Copy, creates a GEDI Record, and transmits that Record 
to a Consumer, perhaps via one or more Relays 

4 Symbols and abbreviated terms 

FTP 

File Transfer Protocol 

JFIF 

JPEG File Interchange Format 

JPEG 

Joint Photographic Experts Group 

MIME 

Multipurpose Internet Mail Extensions 

PDF 

Portable Document Format 
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POP 

Post Office Protocol 

RFC 

Request for Comment; and Internet standard or proposal 

SMTP 

Simple Mail Transfer Protocol 

TIFF 

Tagged Image File Format 

5 Service model and topology 

5.1 Introduction 

As tfie name indicates, the Generic Electronic Document Interchange (GEDI) is concerned with the interchange of 
documents in electronic form. From this concern, the emphasis of this Internationa! Standard lies in two areas: 

a) the definition of an Electronic Document Format; 

b) the description of the Interchange mechanism. 

This concern is less wide in scope than that necessary to provide an Electronic Document Delivery service. 
Interchange is only a part of the whole process. To provide a complete delivery service, several other issues have 
to be addressed besides the two covered by GEDI. 

The following elements are relevant to the complete delivery cycle of electronic documents. 

a) Identifying and locating — where the document is identified and the source location is established. This can 
be done through the use of on-line union catalogue access (for example using the ISO 23950 standard), or 
through off-line services such as CD-ROMs or paper catalogues. 

b) Ordering — where the required document is requested for delivery. This is functionally identical with issuing 
an Interlibrary Loan request. The GEDI Header information described in clause 7 takes the ISO ILL standard 

(ISO 10160) as a guideline for the document identification. 

c) Digitization — where a hard-copy document is transformed into an electronic image. This will be done 
through a scanning device. 

d) Interchange — where the actual transfer of the electronic copy takes place. 

e) Hard-copy reproduction — where the document's image is converted back to paper or other media. This will 
be done through a printing device. 

f) Billing, accounting and other administrative procedures. 

All these elements can occur in several forms in practical situations; some might not be relevant in specific cases. 

Interchange is a key element in this list as it effectuates the physical movement of a copy of a document. Other 
elements from the list could be absent in specific cases: 

— identification and locating could be based upon common knowledge; 

— ordering is not relevant in case of unsolicited delivery; 
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— digitalization is not necessary when documents have already been digitized, either through direct electronic 
publishing or through scanning and storing; 

— reproduction can be skipped when an electronic copy is to be kept on a storage medium; 

— billing and accounting are not relevant in cooperative services where participants share load and costs 
between them. 

Therefore, the agreements reached in GEDI concentrate on interchange to provide common ground for the 
development of electronic document delivery services. On this basis, different electronic document delivery 
services would have the characteristics to easily enable development of links between them. Also, the development 
of the other elements constituting a full delivery service will benefit from international agreement on the interchange 
part. 

The overall model that forms the basis of the International Standard within the scope of the interchange element of 
document delivery services is a global model. The source information that GEDI is concerned with, document 
images, is located around the world in various places. Likewise, the target clients of document delivery services are 
widely distributed. The model accommodates all sources and targets. 

Furthermore, the model should recognize the responsibilities of a wide variety of organizations involved in 
document delivery to implement private solutions. In general, private solutions reflect agreements that exist 
between groups of organizations to optimize services between them. The GEDI model does not limit the 
possibilities and freedom of such agreements. In the end, the overall model aims at establishing common ground 
and direction guidelines for further development, to provide the possibility of interworking between such different 
groups. 

5.2 General model 

The general model for the interchange process for electronic document delivery is represented in Figure 1. The 
main characteristics of the model can be described as follows: 

a) the interchange involves two parties, the Supplier and the Consumer; 

b) the Supplier and Consumer are linked through a facility enabling the transfer of an electronic document from 
Supplier to Consumer; 

c) the transfer handles one document at a time. 

SUPPLIER CONSUMER 

^Transaction-^ 



INPUT 



SUPPLY 



TRANSMIT 



OUTPUT 



CONSUME 



RECEIVE 



TRANSFER 



Figure 1 — General model for electronic document Interchange 

The complete cycle of interchange, starting with an electronic document residing with the Supplier and terminating 
with the completed delivery of that document to the Consumer is called a Generic Electronic Document 
Interchange Transaction. 

It is important to note that the input and output functions as shown in Figure 1 do not participate in the transaction. 
The exact nature of these functions is outside the scope of this International Standard. Of course, in practical 
situations, some form of input and output will be available: 

— input can come from hard-copy documents through scanning (the most probable form in the short term), from 
files with stored document images, or from electronically published documents; 



IS 15389 : 2003 
ISO 17933 : 2000 

-— output can take the form of inserting an electronic document into a storage file, or printing. The implementation 
of some of these possibilities may be dependent on legal and copyright regulations. 

5.3 The Domain concept 

The model can be broken down into smaller parts by introducing the concept of Domains. This concept allows the 
solutions under private responsibilities in private Domains to be distinguished and made more or less independent 
of the solution on the common, international, GEDI domain. Common agreement is only required within the GEDI 
domain; GEDI might or might not be followed in private Domains. 

The various private Domains will be interconnected through the services in the GEDI domain. Generally, private 
services are available on the basis of a variety of functional and network models reflecting the organizational 
structure within the private domain. From the definition of this International Standard, ''the Relay functions to be 
provided on the boundary between private and GEDI Domain can be specified. 

A Domain is defined as a group of one or more Suppliers and one or more Consumers capable of engaging in 
Electronic Document Interchange Transactions between them, where a common agreement exists in the following 

areas: 

a) electronic document interchange format and compression algorithm; 

b) electronic document transfer mechanism; 

c) network technology. 

The Domain agreements not only specify which mechanism or standard to use, but also select the appropriate 
options to be used by the Domain members. In this sense, the Domain members agree on a common profile. This 
reduces the complexity of the development of systems that form part of the domain. 

In practice, the Domain agreements cover all communication layers, whether they conform to International 
Standards and the OSI model or not. For example, the agreements in a particular Domain might specify 
communication on the basis of FTP over TCP/IP; another Domain might use MIME over TCP/IP. 

In the application layer, agreements on the document format are as important for the Domain as the communication 
profile. In such a context. Suppliers and Consumers share the same view of an electronic document, and do not 
need functions for converting and reformatting. 

Using this Domain concept, it follows that a Supplier and a Consumer within the same Domain are capable of 
interconnecting directly. Conversely, if they form part of different Domains, they might not be able to do so, 
depending on whether the two Domains share the same agreements or not. Note that two Domains that are 
administratively separate may still share a common profile. 

If the two Domains do not share the same agreements, the interconnection will be realized through an Application 
Relay function. The Application Relay will receive a GEDI Record using transfer mechanisms under the agree- 
ments of the first domain, and will transfer the record to the second Domain under the agreements of the second 
domain. Figure 2 sketches out the role of the Application Relay. 
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Figure 2 — Interchange across two Domains 
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Still, in the model of Figure 2, the Generic Electronic Document Interchange Transaction exists between Supplier 
and Consumer, with the Relay playing a supporting role 

5.4 Functional elements 

In Figure 2, all the model elements where Domain boundaries have to be crossed are shown. This model can be 
extended even further in cases where two Domains do not share a common Relay, but both have a Relay to a third 
domain. Subclause 5.5 will put this in context in the GEDI environment. 

In this subclause, an overview of the functional elements shown In Figure 2 is given, together with the following 
characteristics of these elements. 

a) Input 

This function is responsible for making an Electronic Document Copy available to the Supplier. The Supplier 
will only handle Electronic Document Copies in the agreed image format, so the input function produces 
Electronic Document Copies within the Domain agreements on Electronic Document Copy format. Examples 
of the input function are: scanning a hard-copy document; and reading an electronic document from a storage 
device. 

b) Supply 

This function takes the result of the input function, the Electronic Document Copy, and produces a data 
structure to be transferred by adding information relevant to the transaction. This additional information is 
referred to as GEDI Header information, including the identification of the transaction, possibly a reference to 
an ILL transaction, the identification of the Electronic Document Copy, and information about the Supplier and 
Consumer. The supply function can also store the Electronic Document Copy temporarily before it is actually 
transferred, for example in situations where batches of Electronic Document Copies are being prepared for 
overnight transfer. 

c) Transmit 

This function takes care of the actual sending of the Electronic Document Copy and the GEDI Header 
information through a network. The transfer function includes the complete communications stack, with all the 
applications and lower layer protocol services in the initiator or originator role. 

d) Receive 

This function is the counterpart of the transmit function, and enables the receiving of the GEDI Record from the 
network. It is implemented using the same communication profile as the corresponding transmit function; it 
acts in the target or responder role. 

e) Consume 

This function receives the GEDI Record, and analyses the content of the GEDI Header information to 
determine what actions should be taken. Generally, it will present the Electronic Document Copy to an 
appropriate output function. At the same time, the GEDI Header information can be passed to other 
applications, for example for administrative purposes. 

f) Output 

This tu"nctk>n takes care of the final reproduction or electronic filing of the received Electronic Document Copy. 
Examples are: printing of the Electronic Document Copy on a laser or other printer; permanent storage for later 
use. 

g) Forward 

This function provides the possibility of communicating between two Domains. It has the capabilities to convert 
between the agreements of two Domains. In effect, it is located on the boundary of the two Domains, taking in 
GEDI Records from the one Domain and sending out GEDI Records in the other. 

The functional elements described above combine within the model into the main model entities as follows: 

— The entity SUPPLIER can be thought of as an application process with the functions: input, supply and 
transmit. 

— The entity CONSUMER is the application process with the functions: receive, consume and output. 
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— The entity RELAY is the application process with the functions: receive (in one donnain), fonward and transmit 
(in another domain). 

5.5 GEDI topology 

In the GEDI environment, a number of private Domains will exist. These private Domains can be further subdivided 
into sub-Domains, for example where regional services link up to form a national service. 

Relays between the private Domains and the GEDI Domain can be developed on theljasis of this International 
Standard. 

Figure 3 depicts the communication between a Supplier and a Consumer that belong to two different private 
Domains, using the services of two Relays. 
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Figure 3 — Communication through the GEDI domain 



The abstract model definition in the previous subclauses describes all the entities and functional elements involved 
in Electronic Document Interchange. In a practical situation, these elements will be implemented through programs 
on computer systems, communicating through physical network links. 



6 GEDI Record format structure 

Documents will be exchanged in a GEDI Record, the format of which consists of two parts: 

a) the GEDI Header (cover information); 

b) the Electronic Document Copy. 

By separating the GEDI Header from the Electronic Document Copy, Relay systems are relieved of the require- 
ment to be able to read the document image format. This approach also makes it easier to accommodate new 
document-fomiats in the future. See Figure 4. 



: 



GEDI HEADER: 

Document Interchange Format Information (Type 1) 

Destination and Storage Information (Type 2) 

Electronic Document Delivery Transaction Information (Type 3) 

Document Description (Type 4) 

Padding if necessary (Type 5) 



Electronic Document Copy 



Figure 4 — GEDI Record Interchange Format 
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The GEDI Record may be transferred by a number of different mechanisms in different Domains, such as file 
transfer protocols (e.g. FTP) or email protocols (e.g. MIME). The existence of Relays between different Domains 
means that a single GEDI Record may be transferred by several different mechanisms in passing from Supplier (in 
one Domain) to Consumer (in another). Therefore, the format of the GEDI Record is independent of the transfer 
mechanism and makes no assumptions about the transfer mechanisms (other than that they can handle 8-bit data 
and have error detection). 

7 The GEDI Header 

7.1 General 

The GEDI Header Information is classified into five types. 

— Type 1 : identifying information about the Document Interchange Format itself. 

— Type 2: naming, time, destination, and storage information for the Transfer Mechanism. 

— Type 3: other information about the particular Electronic Document Delivery Transaction. 

— Type 4: information specific to the document, including a brief bibliographic description. 

— Type 5: padding to allow for subsequent changes to the GEDI Header without changing the GEDI Header 
length (optional). 

NOTE 1 The GEDI Header data elements, whether mandatory or optional, are singly occurring and cannot be repeated. 

NOTE 2 The Supplier always has the option to include an actual cover page as part of an Electronic Document Copy, in 
addition to supplying the GEDI Header data elements. 

7.2 GEDI Header data elements — semantics 
7.2.1 introduction 

The following data elements make up the GEDI Header for transmission; the Consumer system may print them on 
a cover sheet for the GEDI Record as appropriate. In order to facilitate operation of this Electronic Document 
Delivery service with Interlibrary Loan applications, the data elements below are aligned with those defined in the 
ILL protocol standard, ISO 10161, wherever possible. Details of the mapping of ILL-Request Data Elements to 
GEDI tags are given for information in annex A. The occurrence of "10161" at the end of a definition indicates that 
the data element is aligned with the data element of the same name in the ILL protocol standard. 

The "Structure" field specifies the data type for a data element. The following data types are used: 

— character-string: ASCII 20 ... 7E; i.e. all the ASCII graphic characters 

— numeric: ASCII 30 ... 39; i.e. ... 9 

— alphanumeric: ASCII 30 ... 39 41 ... 5A61 ... 7A; i.e. 0... 9 A ... Za ... z 

NOTE Service-string-advice, SSAD, reserves some characters for special use in structured tags. 
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7.2.2 TYPE 1 — Document interchange format information 

Name: interchange-format-id 

Tag: IFID 

Semantics: an unambiguous identifier of the document interchange format; it identifies botli the abstract syntax and the 

encoding 

Structure: character-string 

Status: mandatory 

Max. length: 20 

Example: GEDI 

Name: interchange-format-version 

Tag: IFVR 

Semantics: a version number for the Interchange Format Id 

Structure: character-string 

Status: mandatory 

Max. length: 20 

Example: 3.0 

Name: cover-information-length 

Tag: CILN 

Semantics: the length of the GEDI Cover information (including the IFID and the IFVR); serves as an offset to the 
beginning of the Electronic Document Copy from the beginning of the GEDI Record; this is a character 
representation of a decimal number specifying the byte count of ALL of the GEDI Cover information 

Structure: numeric 

Status: mandatory 

Max. length; 10 (padding fields included if present) 

Example: 123 

Name: document-format-id 

Tag: DFID 

Semantics: an unambiguous identifier of the format of the Electronic Document Copy in this GEDI Record; possible 

values include OlDs and MIME types. See annex B for a current registry of identifiers 

Structure: character-string 

Status: mandatory 

Max. length: 20 

Examples: TIFF-5.0, TIFF-6.0, PDF-1.1 



Name: service-string-advice 

Tag: SSAD 

Semantics: a selection of characters for use as delimiters and indicators in Type 2, Type 3, and Type 4 data elements; 
used to provide information about the structure of elements. Each character must be set on a specified place 
in the string; use the following order: 

First character: release indicator 

Second character: delimiter/separator between items 

prefix of new subsegment. A one-positiBn predefined alphanumeric character 
always precedes the "=" symbol 
opening bracket to start a nested structure 
closing bracket to end a nested structure 
Four characters are used for subsegmenting and must be set in the service string: 

as delimiter between items in a structured tag 
"=" as prefix of new subsegment; a one-position predefined 
alphanumeric character always precedes the "=" 



Third character: 

Fourth character: 
Fifth character: 



NOTE 



"(" as opening bracket to start a nested structure 
")" as closing bracket to end a nested structure 
This was inherited from the'EDIFACT encoding 
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Structure: character-string 

Status: mandatory 

Max. length: 50 

Example: ?;={) 



7.2.3 TYPE 2 — Destination and storage information relevant to the transfer mechanism 

Name: Consumer-name 

Tag: CNSN 

Semantics: an unambiguous indication of the destination ot the GEDI Record. Its preferred transfer mechanism and the 

system address are also included; this is an ordered list of preferred destinations. At least one value is 

required. 
Structure: alphanumeric, structured. Name (N=); Email (E=); FTP address/directory (F=); Faxnr {X=). FTP must be 

substructured into Address (A=) and Directory (D=); multiple occurrences of Consumer-name are represented 

by repetitions of this sequence of subtags. 
Status: mandatory 

Max. length: 250 
Example: F=(A=12911004352;D=LGR.DOC);N=PICA 

Name: record-name 

Tag: RCNM 

Semantics: The name of the GEDI Record. The name is assigned by the Supplier so as to be unambiguous, it must 

follow the rules for Filenames as described in 9.2. 

Structure: character-string 

Status: mandatory 

Max. length: 32 

Example: RUGOPC2232 

Name: supplier-name 

Tag: SPLN 

Semantics: The unambiguous indication of the source of the GEDI Record. At least one value is required. 

Structure: alphanumeric, structured. Name (N=); Email (E=); FTP address/directory (F=); Faxnr (X=). FTP must be 

substructured into Address (A=) and Directory (D=) 

Status: mandatory 

Max. length: 250 

Example: F=(A=:1291 1004352;D=LGR.DOC);N=RLG 

Name: service-date-time 

Tag: SVDT 

Semantics: the local date and time that the Supplier created this GEDI Record for transmission 

Structure: numeric YYYYMMDDHHMMSS (conforms to ISO 8601 ) 

Status: mandatory 

Max. length: 14 

Example: 19930204122436 

Name: system-service-ld 

Tag: SYID 

Semantics: delivery system identification of the Electronic Document Copy 

Structure: character-string, unstructured 

Status: optional 

Max. length: 50 

Example: DIS 12.12 
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Name: system-service-address 

Tag: SYAD 

Semantics: delivery system address of tlie GEDI Record; 10161 system-address 

Structure: character-string, structured; Email (E=); Printlocation (P=); Faxnr (X=); Print location is substructured in 

Department (D=), Room (R=), Printer name {P=) 
Status: optional 

Max. length: 100 

Example: E=Devries @ ubg.nl;P=(D=development; R= 1 23; P=oakprntr) 

[10161 Definition: no equivalent 10161-1 definition found] 



Name: delivery-service 

Tag: DLVS 

Semantics: a name or code for the delivery service or method to be used in transporting the Electronic Document Copy; 

10161 
Structure: character-string, structured; Name (N=); Email (E=); FTP address/directory (F=); Faxnr (X=). FTP must be 

substructured into Address (A=) and Directory (D=) 
Status: optional 

Max. length: 50 

Example: F={A=12911004352;D=LGR.DOC) 

[10161 Definition: A name or code for the delivery service or method to be used in transporting the item (no change).] 



Name: 

Tag: 

Semantics: 

Structure: 

Status: 
Max. length: 
Example: 



confirmation-address 
CNFA 

an address for the confirmation of the transfer of a GEDI Record between two delivery systems 

character-string, structured; Name (N=); Email (E=); FTP address/directory (F=); Faxnr (X=). FTP must be 

substructured into Address (A=) and Directory (D=) 

optional 

50 

F=(A=12911004352;D=LGR.DOC) 



7.2.4 TYPE 3 — Transaction information 



Name: 


priority 




Tag: 


PRTY 




Semantics: 


the priority to be given to this Electronic Document Delivery Transaction; is the lowest priority, 9 is the 




highest 




Structure: 


numeric; number 0-9 




Status: 


optional 




Max. length: 


1 




Example: 







Name: 


general-note 




Tag: 


GNLN 




Semantics: 


a free text message from the Supplier to the Consumer 




Structure: 


character-string; unstructured 




Status: 


optional 




Max. length: 


600 




Example: 


End-page of article not sure 




Name: 


client-name 




Tag: 


CLNT 




Semantics: 


the name of the reader for whom the Electronic Document Copy is intended; 10161 




Structure: 


character-string, structured; Email (E=); Name (N=) 




Status: 


optional 




Max. length: 


50 




Example: 


E=devries@pica.nl;N=De Vries 





[10161 Definition: Name of the person or institution for which the item has been requested.] 
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Name: client-id 

Tag: CUD 

Semantics: the identifier of ttie reader tor whom the Electronic Document Copy is intended (e.g. library patron number); 

10161 

Structure: character-string, unstructured 

Status: optional 

Max. length: 25 

Example: LIB1 234567 



[10161 Definition: Number or code used to identify the client uniquely.] 

Name: client-status 

Tag: CLST 

Semantics: the status of the reader for whom the Electronic Document Copy is intended; 10161 

Structure: character-string, structured. Country code conforms to ISO 3166-1: Code for the representation of names of 

countries and their subdivisions {L=); Status (S=) 
Status: optional 

Max. length: 25 
Example: L=NL;S=lng 

[10161 Definition: Professional level or position of the client.] 

Name: name-of-person-or-institution 

Tag: NPOl 

Semantics: the name component of the postal address to which the Electronic Document Copy is to be delivered; 10161 

Structure: character-string, unstructured 

Status: optional 

Max. length: 150 

Example: Royal Library 

[10161 Definition(s): name-of-institutlon: A word, phrase or abbreviation which identifies a library, institution or corporation; 
name-of 'Person: A word or combination of words and/or initials by which an individual is regularly known or designated and 
which identifies the person participating in the ILL-transaction.] 

Name: extended-postal-delivery-address 

Tag: XPDA 

Semantics: the miscellaneous component of the postal address to which the item is to be delivered 

Structure: character-string, unstructured 

Status: optional 

Max. length: 100 

Example: ILL Department 

Name: street-and-number 

Tag: STNM 

Semant!f:s: the street and number component of the postal address to which the item is to be delivered; 10161 

Structure: character-string, unstructured 

Status: optional 

Max. length: 128 

Example: Schipholweg 99 

[10161 Definition: A number and/or phrase used to identify the location of a building within a city or a rural area.] 
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Name: post-office-box 

Tag: POBX 

Semantics: the post office box component of the postal address to which the item is to be delivered: 10161 

Structure: character-string, unstructured 

Status: optional 

Max. length: 40 

Example: Postbus 67 

[10161 Definition: A box number assigned by the post office.] 

Name: city 

Tag: CITY 

Semantics: the city component of the postal address to which the item is to be delivered; 10161 

Structure: character-string, unstructured 

Status: optional 

Max. length: 128 

Example: Maastricht 

[10161 Definition: A ptirase used to identify a city, town or village.] 

Name: region 

Tag; REGN 

Semantics: the region component of the postal address to which the item is to be delivered; 10161 

Structure: character-string, unstructured 

Status: optional 

Max. length: 128 

Example: Limburg 

[10161 Definition: A ptirase used to identify a province, state, region or locale.] 

Name: country 

Tag: CNTR 

Semantics: the country component of the postal address to which the item is to be delivered; 10161 

Structure: character-string, unstructured 

Status: optional 

Max. length: 50 

Example: The Netherlands 

[10161 Definition: A phrase used to identify a country.] 

Name: postal-code 

Tag: POCD 

Semantics: the postal code component of the postal address to which the item Is to be delivered; 10161 

Structure: character-string, unstructured 

Status: optional 

Max. length: 40 

Example: 2634AC 

[10161 Definition: A code whicti identifies a given area within a city or other geographical area.] 



Name: requester-id 

Tag: RQID 

Semantics: information identifying the library (system) which generated the ILL request, typically an ILL office; 10161 

Structure: character-string, unstructured 

Status: optional 

Max. length; 25 

Example: 0019/0000 

[10161 Definition: Identification information of the ILL-transaction requester Note: the requester will not always be a library!] 
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Name: requester-name 

Tag: RQNM 

Semantics: name of the library (system) wliich generated the request for the document; 101B1 

Structure: character-string, structured; Name (N=); Email (E=); FTP address/directory (F=:); Faxnr (X=). FTP must be 

substructured into Address (A=) and Directory (D=) 

Status: optional 

Max. length: 1 50 

Example: N=RUU;E=OPC@ruu.n 

[10161 Definition: requester-id: Identification information of the ILL-transaction requester.] 

Name: responder-id 

Tag: RSID 

Semantics: information identifying the library (system) which satisfies the request for the document; 10161 

Structure: character-string, unstructured 

Status: optional 

Max. length: 25 

Example: 0019/0000 

[10161 Definition: Identification information oftfie ILL-transaction responder.J 

Name: responder-name 

Tag: RSNM 

Semantics: name of the library (system) which satisfies the request for the document; 10161 

Structure: character-string, structured; Name {N=); Email (E=); FTP address/directory (F=); Faxnr (X=). FTP must be 

substructured into Address (A=) and Directory (D=) 

Status: optional 

Max. length: 150 

Example: F=(A=12900045;D=KGH.DOC) 

[10161 Definition: responder-id: Identification information of the ILL-transaction responder.} 

Name: copyright-compliance 

Tag: CPRT 

Semantics: requester notation indicating the applicable copyright regulations or laws to which the requester is adhering; 

10161 

Structure: character-string, structured; Code (C=); Note (N=) 

Status: optional 

Max. length: 1 50 

Example: C=1 ;N=Only private use 

[10161 Definition: Requester notation indicating the applicable copyright regulations or law to which the requester is adhering.] 

Name: ILL-transaction-id 

Tag: ILTI 

Semantics: information which uniquely identifies an ILL transaction related to this Electronic Document Delivery 

Transaction; 10161 
Structure: character-string, structured; Symbol (S=); Name (N=); Group qualifier (G=); Qualifier (Q=); Subqualifier (B=) 

Status: optional 

Max. length: 25+150+25+25+25+(5*4)=270 
Example: S=1 200/0000; N=RUU;G=ION;Q=1234;B=1 

[10161 Definition: transaction-qualifier: An alphanumeric string identifying all services and messages associated with a single 
ILL-transaction. Note that this is. a unique string assigned by the initial requester of the ILL-transaction and applied by the ILL 
partners to all subsequent services and messages associated with the ILL-transaction. In combination with the requester's id 
and the transaction-group-qualifier, this provides a universally unique identification for the ILL-transaction.] 
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Name: responder-note 

Tag: RSNT 

Semantics: a free text message from the party which is responding to the ILL request; 10161 

Structure: character-string, unstructured 

Status: optional 

Max. length: 600 

Example: Last page missing 

[10161 Definition: Note provided by the ILL-transaction responder.] 

Name: receive-control 

Tag: RCON 

Semantics: information which controls the actions that the receiver is allowed to perform on the received item. 

Structure: character-string, structured: D (print and delete only), F (forwarding NOT allowed), P (print only), V (view 

only), X (delete if forwarded) 

Status: Optional for Supplier, if present mandatory for receiver 

Max. Length 1 

Example: D 



7.2.5 TYPE 4 — Document description 

Name: author 

Tag: ATHR 

Semantics: 10161 

Structure: character-string, unstructured 

Status: optional 

Max. length: 125 

Example: James, E.R. 

[10161 Definition: Name of tfie person or corporate body responsible for tiie intellectual or artistic content of an item, including 
composers, creators or originators of an item.] 

Name: title 

Tag: TTLE 

Semantics: This is the title of the serial, monograph, or whatever, from which the document is extracted. 

Structure: character-string, unstructured 

Status: optional 

Max. length: 250 

Example: Journal of the American Chemical Society 

[10161 Definition: Name of an item consisting of a word or group of words intended to identify it] 

Name: volume-issue 

Tag: VLIS 

Semantics: 10161 

Structure: character-string, structured; Volume (V=); Issue (l=); Combined (B=) 

Status: optional 

Max. length: 25 

Example: V=1.2 

[10161 Definition: Identifier of a physical unit of a serial or multi-volume monograph/number, letter or word identifying a unit of 
an item which is, or the volumes which are, published in parts.] 
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Name: author-of-article 

Tag: AART 

Semantics: 10161 

Structure: character-string, unstructured 

Status: optional 

Max. length: 125 

Example: Jones, Q.X. 



[10161 Definition: Author of an item which is a component part of another item.] 



Name: 

Tag: 

Semantics: 

Structure: 

Status: 

Max. length: 

Example: 

[10161 Definition: Title of an item which is a component part of another item.] 



title-of -article 
TART 

the title of the document being transmitted 

character-string, unstructured 

optional 

250 

From Babel to EDIL - the evolution of a standard 



Name: ISBN 

Tag: ISBN 

Semantics: International standard book number, as defined in ISO 21 08:1 992 Documentation — international 

Standard booi< numbering (ISBN); 10161. 

Structure: alpha-numeric 

Status: optional 

Max. length: 10 

Example: 1 234567890 

[10161 Definition: The International Standard Book Number assigned to a monograph as prescribed by ISO 2108:1992.] 

Name: ISSN 

Tag: ISSN 

Semantics: an unambiguous identification code for serial publications, as defined in ISO 3297:1998 

Documentation - International Standard serial numbering (ISSN); 10161 

Structure: alpha-numeric 

Status: optional 

Max. length: 8 

Example: 12345678 

[10161 Definition: The International Standard Serial Number assigned to a serial title as prescribed by ISO 3297-1998.] 



Name: 


page-numbers 


Tag: 


PGNS 


Semantics: 


the range(s) of page numbers in the original document that are contained in the electronic copy of the 




document 


Structure: 


character-string, unstructured 


Status: 


optional 


Max. length: 


100 


Example: 


1-23,36 


Name: 


date-scanned 


Tag: 


DTSC 


Semantics: 


the date that the electronic copy of the document was made; this is not necessarily the same as the 




date that the electronic copy was placed within this Document Interchange Format Record 


Structure: 


numeric; YYYYMMDDHHMMSS (conforms to ISO 8601 ) 


Status: 


optional 


Max. length: 


14 


Example: 


19930101123554 



16 



IS 15389 : 2003 
ISO 17933 : 2000 



Name: 


number-of-pages 


Tag: 


NMPG 


Semantics: 


the total number of pages represented in the electronic document copy 


Structure: 


numeric 


Status: 


optional 


Max. length: 


5 


Example: 


123 


Name: 


call-number 


Tag: 


CLNO 


Semantics: 


see ILL-REQUEST under item-id (call number) 


Structure; 


character-string, structured; Journal (J=); Book (B=); Report (R=) and Unknown (U=) 


Status: 


optional 


Max. length: 


50 


Example: 


J=12.9 


Name: 


publication-date-of-component 


Tag: 


PDOC 


Semantics: 


see ILL-REQUEST under item-id (publication date of component) 


Structure: 


character-string, unstructured 


Status: 


optional 


Max. length: 


25 


Example: 


1992 


Name: 


publication-date 


Tag: 


PUBD 


Semantics: 


see ILL-REQUEST under item-id (publication date) 


Structure: 


character-string, unstructured 


Status: 


optional 


Max. length: 


25 


Example: 


2-03-93 


Name: 


place-of-publication 


Tag: 


PLPB 


Semantics: 


see ILL-REQUEST under item-id (place of publication) 


Structure: 


character-string, unstructured 


Status: 


optional 


Max. length: 


128 


Example: 


London 


Name: 


publisher 


Tag: 


PUBL 


Semantics: 


see ILL-REQUEST under item-id (publisher) 


Structure: 


character-string, unstructured 


Status: 


optional 


Max. length; 


50 


Example: 


Harvard University Press 


Name: 


edition 


Tag: 


EDIT 


Semantics: 


see LLL-REQUEST under item-id (edition) 


Structure: 


character-string, unstructured 


Siatus: 


optional 


Max. length: 


25 


Example: 


12A 
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Name: request-as-quoted 

Tag: RQAQ 

Semantics: details of the requested item as quoted by the requester 

Structure: character-string, unstructured 

Status: optional 

Max. length: 600 

Example: Jnl Am Chem Soc. 1 993 642 (3) 341 2-341 7 Smith and Jones 

Name: copyright-statement 

Tag: STAT 

Semantics: a free text message from the Supplier which details any restrictions on the use of the delivered item 

for copyright reasons. 
Structure: character-string, unstructured 

Status: Optional, but, if included, it is mandatory for the statement to be printed out with the item or, if 

displayed on a screen, it is mandatory for the statement to be displayed on the screen 
Max. Length: 600 
Example: Further copying of this document (including storage in any medium by electronic means), other than 

that allowed under copyright law, is not permitted without the permission of the copyright owner or an 

authorized licensing body. 

Name: Item Id 

Tag: ITID 

Semantics: a standard identifier for the item, such as BICI, DOI, SICI, URN 

Structure: character-string, type of identifier (T=); value of identifier (V=); 

Status: optional 

Max. Length: 200 

Example: T=S1CI; V=0002-8231{199412)45:10<737:T10DIM>2.3.tx;2-M 



7.2.6 TYPE 5 — Padding 



Name: 

Tag: 
Semantics: 



Structure: 
Status: 
Max. length: 

Example: 



zpadding 
ZPAD 

the length of this field reserves space for reformatting the GEDI Header; this is done to allow systems 

to change the length of individual data elements in the GEDI Header without changing the total length 

of the GEDI Header; the length of ZPAD can be changed by the amount necessary to compensate 

for the sum of the changes in the length of individual data elements. The contents of the value of 

ZPAD have no significance 

none 

optional 

8k 



7.3 GEDI Header data elements-syntax 

Each data element is represented in a <tag><length><value> structure. Tags are mnemonic alphabetic 8-bit ASCII 
character strings, fixed length of four 8-bit characters, case insensitive. Lengths are decimal integers, represented 
by four ASCII numeric characters, fixed length. Values are string of 8-bit ASCII graphic characters. There are no 
intervening characters, or "white space" of any kind between the <tag> and the <length>, the <length> and the 
<value>, or the <value> and the next <tag>. 

The different types are shown in Tables 1 to 5 
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Tableau 1 — TYPE 1 -Document interchange format information 



Tag 


Name 


Mandatory/ 

Optional 


Max. 
length 


Structure 


IFID 


interchange- 
formal-ici 


M 


20 


character-string 


IFVR 


interchange- 
format-version 


M 


20 


character-string 


CILN 


cover- 

informatlon- 

length 


M 


10 


numeric 


DFID 


document- 
fomiat-id 


M 


20 


character-string 


SSAD 


service-string- 
advice 


M 


50 


character-string 





Tableau 2 


— TYPE 2 


-Destination and storage information 


Tag 


Name 


Mandatory/ 

Optional 


Max. 
length 


Structure 


CNSN 


Consumer-name 


M 


250 


character-string, structured. Name (N=); Email (E=); FTP 
address/directory (F=); Faxnr (X=).FTP must be 
subsiructured into Address (A=) and Directory (D=) 


RCNM 


record-name 


M 


32 


character-string 


SPLN 


Supplier-name 


M 


250 


character-string, structured. Name (N=); Email (E=); FTP 
address/directory (F=); Faxnr (X=). FTP must be 
substructured into Address (A=) and Directory (0=) 


SVDT 


service-date-time 


M 


14 


numeric YYYYMMDDHHMMSS confonns to ISO 8601 


SYID 


system-service-id 


Opt. 


50 


character-string, unstructured 


SYAD 


system-service- 
address 


Opt. 


100 


character-string, structured; Email (E=); Print location (P=); 
Faxnr (X=); Print location must be substructured into 
Department (D=); Room (R=); Printername (P=) 


DLVS 


delivery-service 


Opt. 


50 


character-string, structured; Email (E=); FTP 
address/directory (F=): Faxnr {X=); ISDN address and code 
(l=); FTP must be substructured into Address (A=) and 
Directory (D=) 


CNFA 


confirmation- 
address 


Opt. 


50 


character-string, structured; Email (E=); FTP 
address/directory (F=); Faxnr (X=): FTP must be 
substructured into Address (A=> and Directory (D=) 
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Tableau 3 — TYPE 3— Electronic document delivery transaction information 



Tag 


Name 


Mandatory/ 

Optional 


Max. length 


Structure 


PRTY 


priority 


Opt. 


1 


numeric; number 0-9 


GNLN 


general-note 


Opt. 


600 


character-string, unstructured 


CLNT 


client-name 


Opt. 


50 


character-string, structured; Email (E=); 
Name (N=) 


CLID 


client-id 


Opt. 


25 


character-string, unstructured 


CLST 


client-status 


Opt. 


25 


character-string, structured; Country code 
conforms to ISO 3166-1, Codes for the 
representation of names of countries and 
their subdivisions — Part 1: Country codes. 
(L=); Status (8=) 


NPOl 


name-of-person-or- 
institution 


Opt. 


150 


character-string, unstructured 


XPDA 


extended-postal-delivery- 
address 


Opt. 


100 


character-string, unstructured 


STNM 


street-and-number 


Opt. 


128 


character-string, unstructured 


POBX 


post-otflce-box 


Opt. 


40 


character-string, unstructured 


CITY 


city 


Opt. 


128 


character-string, unstructured 


REGN 


region 


Opt. 


128 


character-string, unstructured 


CNTR 


country 


Opt. 


50 


character-string, unstructured 


POCD 


postal-code 


Opt. 


40 


character-string, unstructured 


RQID 


requester-id 


Opt. 


25 


character-string, unstructured 


RQNM 


requester-nanne 


Opt. 


150 


character-string, structured; Name (N=); 
Email (E=); FTP address/directory (F=); 
Faxnr (X=) FTP must be substructured into 
Address (A=) and Directory (D=) 


RSID 


responder-id 


Opt. 


25 


character-string, unstructured 


RSNM 


responder-name 


Opt. 


150 


character-string, structured; Name (N=); 
Email (E=); FTP address/directory (F=); 
Faxnr (X=) FTP must be substructured into 
Address (A=) and Directory D=) 


CPRT 


copyright-compliance 


Opt. 


150 


character-string, structured; Code (C=); Note 
(N=) 


ILTI 


ILL-transaction-id 


Opt. 


270 


character-string, structured; Symbol (S=); 
Name <N=); Group qualifier (G=); Qualifier 
(Q=);Subqualifier(B=) 


RSNT 


responder-note 


Opt. 


600 


character-string, unstructured 


RCON 


receive-control 


Opt. 


1 


character-string, structured: print and delete 
only (D); do NOT forward (F); print only (P); 
view only (V); delete if forwarded (X) 
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Tableau 4 — TYPE 4-Document description 



Tag 


Name 


Mandatory/ 

Optional 


Max. 
length 


Structure 


ATHR 


author 


Opt. 


125 


character-string, unstructured 


TTLE 


title 


Opt. 


250 


character-string, unstructured 


VLIS 


volume-issue 


Opt. 


25 


character-string, structured; Volume (V=), 
Issue {!=); Combined (B=) 


AART 


author-of-article 


Opt. 


125 


character-string, unstructured 


TART 


title-of-artlcle 


Opt. 


250 


character-string, unstructured 


ISBN 


ISBN 


Opt. 


10 


alpha-numeric 


ISSN 


ISSN 


Opt. 


8 


alpha-numeric 


PGNS 


page-numbers 


Opt. 


100 


character-string, unstructured 


DTSC 


date-scanned 


Opt. 


14 


numeric; YYYYMMDDHHMMSS, conforms to 
ISO 8601 


NMPG 


number-of-pages 


Opt 


5 


numeric, unstructured 


CLNO 


call-number 


Opt. 


50 


character-string, unstructured 


PDOC 


publication-date-of- 
component 


Opt. 


25 


character-string, unstructured 


PU8D 


publication-date 


Opt. 


25 


character-string, unstructured 


PLPB 


place-of-publication 


Opt. 


128 


character-string, unstructured 


PUBL 


publisher 


Opt. 


50 


character-string, unstructured 


EDIT 


edition 


Opt. 


25 


character-string, unstructured 


RQAQ 


request-as-quoted 


Opt. 


600 


character-string, unstructured 


STAT 


copyright-statement 


Opt, 


600 


character string, unstructured 


ITID 


item id 


Opt. 


200 


character string, structured; type of identifier 
(T=); value of identifier (V=); 



Tableau 5 — TYPE 5--Padding 



MNEM 


Name 


Mandatory/ 

Optional 


Max. 
length 


Structure 


ZPAD 


zpadding 


-Opt. 


8k 


none 
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7.4 Tag list in alphabetical order 



TAG 


type 


Name 


AART 


4 


author-ot-article 


ATHR 


4 


author 


CILN 


1 


cover-information-length 


CITY 


3 


city 


CLNO 


4 


call-number 


CLID 


3 


client- id 


CLNT 


3 


client-name 


CLST 


3 


client-status 


CNFA 


2 


confirmation-address 


CNSN 


2 


Consumer-name 


CNTR 


3 


country 


CPRT 


3 


copyright-compliance 


D-FID 


1 


document-format-id 


DLVS 


2 


delivery-service 


DISC 


4 


date-scanned 


EDIT 


4 


edition 


GNLN 


3 


general-note 


IFID 


1 


interchange-format-id 


IFVR 


1 


interchange-format-version 


ILTl 


3 


ILL-transaclion-id 


ISBN 


4 


ISBN 


ISSN 


4 


ISSN 


ITID 


4 


Item-id 


NMPG 


4 


number-of-pages 


NPOl 


3 


name-of-person-of-institution 


PDOC 


4 


publication-date-of-component 


PGNS 


4 


page-numbers 


PLPB 


4 


place-of-publication 


POBX 


3 


post-office-box 


POCD 


3 


postal-code 


PUBD 


4 


publication-date 


PUBL 


4 


publisher 


PRTY 


3 


priority 


RCNM 


2 


record-name 


RCON 


3 


receive-contro! 


REGN 


3 


region 


RQAQ 


4 


request-as-quoted 


RQID 


3 


requester-id 


RQNM 


3 


requester-name 


RSID 


3 


responder-id 


RSNM 


3 


responder-name 


RSNT 


3 


responder-note 


SPLN 


2 


Supplier-name 


SSAD 


1 


service-string-advice 


STAT 


4 


copyright-statement 


STNM 


3 


street-and-number 


SVDT 


2 


service-date-time 


SYAD 


2 


system-service-address 


SYID 


2 


system-service-id 


TART 


4 


title-of-article 


TTLE 


4 


title 


VLIS 


4 


volume-issue 


XPDA 


3 


extended-postal-delivery-address 


ZPAD 


5 


zpadding 
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7.5 Sample GEDI Header 

IFiD0004GEDIIFVS00032.0CILN00042048DFID0608TIFF6.0SSAD0005?;=()CNSN0006N=PICARCNM0008RLGO 
0001SPLN0005N=RLGSVDT001419910802140600TTLE0012PC/ComputingAART0013Paul 
SomersonTART0031The DOS you've been waiting forZPAD1860 



tag 


IFID 


len 


0004 


value 


GEDI 


tag 


IFVS 


len 


0003 


value 


3.0 


tag 


CILN 


len 


0004 


value 


2048 


tag 


DFID 


len 


0008 


value 


TIFF-6.0 


tag 


SSAD 


len 


0005 


value 


?;=() 


tag 


CNSN 


len 


0006 


value 


N=PICA 


tag 


RCNM 


len 


0008 


value 


RLG00001 


tag 


SPLN 


len 


0005 


value 


N=RLG 


tag 


SVDT 


len 


0014 


value 


19910802140600 


tag 


TTLE 


len 


0012 


value 


PC/Coniputing 


tag 


AART 


len 


0013 


value 


Paul Somerson 


tag 


TART 


len 


0031 


value 


The DOS you've been waiting for 


tag 


ZPAD 


len 


1860 


value 


[blanks] 
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8 Electronic document format 

8.1 General 

GEDI supports various formats for the representation of documents in electronic form, such as TIFF, PDF and 
JPEG. 

As indicated in clause 6, the structure of the GEDI Record is designed to accommodate easily additional formats 
for representation of documents, such as ODA or SGML, in the future. 

8.2 Document format identification 

The Document Format Identification (DFID) field in the GEDI Header specifies the format of the electronic 
document copy in any given GEDI record. See annex B for registration of document formats and corresponding 
values of DFID. 



9 File transfer mechanism 

9.1 Introduction 

This International Standard is defined with the intention that it should be possible for a document to be exchanged 
as a single file (the "GEDI record") between transmitter and receiver. For this purpose, GEDI attempts to support 
existing standards, protocols and profiles selected by existing International Standardization groups for simple file 
transfers. 

The choice of file transfer mechanism is the Internet FTP protocol. 

While the general intention is to make this International Standard as independent as possible of the specific 
transfer mechanism adopted, it is recognized that the choice of mechanism requires that certain additional features 
be specified. This amounts to defining a profile for the protocol in question. 

Subclauses 9.2 to 9.6 specify such a profile for FTP. 

9.2 Filenames 

In order to avoid potential conflicts, documents have to be exchanged with unique filenames. These filenames will 
be used all the way from Supplier to Consumer. Therefore, they must be usable on a large number of computers. 

A filename will have to conform to the following rules: 

— 8 characters long, followed optionally by a "." separator and a three character extension; 

— contains only uppercase (A, B, C, ..., 2) and digits (0, 1 , ..., 9), except for the separator; 

— consists of a unique system ID, followed by a sequence number. 

The serial number is chosen by the Supplier in order to be unique (for this Supplier) within a time interval that will 
avoid ambiguous reuse of the serial number. 

One of the acceptable forms of filename is one based on an !P address. This type of filename must conform to the 
following rules: 

— 12 characters long; 

— the first eight characters are a hexadecimal representation of the IP address; 
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— the ninth character is a "." separator; 

— the last 3 characters are a serial number. 

9.3 FTP introduction 

The transmitter will act as the client, initiating the control connection and sending the files. The receiver will act as 
the server, listening for incoming control connections, including receipt of the Store (STOR) command, and receive 
files from the client. 

9.4 FTP implementation profile 

Aspects indicated in bold face type are essential to the GEDI application. 

USE RFC 959 File Transfer Protocol minimum implementation (Clause 5.1) plus Image Data Type (Clause 
3.1.1.3) and the Password (PASS) and Allocate (ALLO) commands. GEDI files will always be sent in the 
IMAGE Representation Type, the STREAM Transfer Mode, and the FILE Structure. 

TYPE - ASCII Non-print and IMAGE* 
MODE - Stream 
Structure - File, Record 
Commands - 

User Name (USER) 
Logout (QUIT) 

Data Port (PORT) 

Representation Type (TYPE) for ASCII Non-print and Image 

Transfer Mode (MODE) 

File Structure (STRU) for File and Record 

RETRIEVE (RETR) 

STORE (STOR) 

NOOP 

Password (PASS) 

Allocate (ALLO) 

NOTE The elements marked with an asterisk (*) are in addition to the minimum implementation specified in 
RFC 959, Clause 5.1 



9.5 Supporting protocol stack for FTP 

FTP will run over TCP/IP. 
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9.6 FTP naming and addressing 

FTP will be accessible at the "well-known ports" for FTP, Port 21 for connmands and Port 20 for data, at the host 
address for each system. 

10 Mail transfer mechanism 

10.1 Introduction 

When a GEDI record is sent via email, the entire GEDI recprd is contained within a single email message. Within 
that single message, the machine-readable GEDI Header is carried in a separate body part from the body part 
used for the optional human-readable GEDI Header or from the body part used for the document copy. 



Body part A 


GEDI Header (required ) 


Body part A' 


human-readable GEDJ Header (optional ) 


Body part B 


document copy (required) 



The proposed format allows the primary Content-Type GEDI Header of the\message to specify explicitly that this is 
a GEDI record. This has the advantage that specialized GEDI-viewing software may be employed by the user 
agent to display/print/handle the document. 

Where an application does not recognize the new GEDI MIME type, it should treat the message as a 
multipart/mixed message; where it does not understand any of the constituent parts, it should allow the user to 
specify a file to store them in. 

10.2 MIME implementation profile 

The overall message content-type GEDI Header is: 
Content-Type: multipart/gedi-record 

No parameters are defined. 

10.2.1 The GEDI Header Body part-required 

The first body part is the machine-readable GEDI Header, that is the GEDI Header in the syntax defined in clause 6 
and 7. The machine-readable form is a new MIME content type, application/gedi-header, this will allow GEDI- 
specific software to use it, and to specify that this is in GEDI Header syntax. 

The Content-Transfer-Encoding: quoted-printable is used for this body part since the GEDI Header syntax does not 
use new line characters and therefore can generate lines longer than 76 characters. The Content-Type line for this 
body part may have a parameter charset=, this is mandatory if the body contains characters outside the US-ASCII 
character set. 

When the optional Human-Readable GEDI Header (see below) is NOT present, the form of the MIME message is 
as shown in Table 6. 
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Table 6 — GEDI-Record MIME Structure without the Human-Readable GEDI Header 



GEDI Header 

Body Part 



Electronic 
Document 

Body Part(s) 



Content-type : TOultipart/gedi-record; 

boundary^ " <unique-boundaryl> ' 
--<unique-boundaryl> 



Content-type : application/ gedi-header 

Content- transfer-encoding: quoted-printable 
<gedi header > 



-<unique-boundaryl> 



Content-type: image/tiff 

Content- transfer-encoding : base64 
<the document> 



--<unique-boundaryl>- 



10.2.2 The Human-Readable GEDI Header Body part-optional 

The human-readable part, if present, uses a MIME media type appropriate for the contents, i.e. determined by the 
originator of the messages. This is most likely to be text/plain with an appropriate character set, and text/plain is 
used here as an example. This part is optional. If the human-readable form uses non-US-ASCII characters and/or 
has lines longer than 76 characters, it should be encoded using quoted-printable rather than base64, to allow 
maximum opportunity for it to be displayed in human-readable 1orm. 

Unlike the GEDI Header, the content and format of the Human-Readable GEDI Header is not defined by this 
International Standard. The content and format of this GEDI Header is left to the discretion of the implementation. 
No assumptions can be made about the content and format of this GEDI Header. 

When the optional Human-Readable GEDI Header is present, both the GEDI Header and the Human-Readable 
GEDI Header will be contained in a body part of content-type: multipart/mixed as shown in Table 7. 



Table 7 — GEDI-Record MIME Structure with the Human-Readable Header 



GEDI Header 

Body part 



Human-Readable 

Body Part 



Electronic 
Document 

Body Part(s) 



Content-type : raultipart/gedi-record; 

boundary= " <unique-boundaryl> " 
--<unique-boundaryl> 




Content-type: multipart/mixed; | 

boundary="<unique-boundary2>" | 
--<unique-boundary2> | 




Content-type: appIication/gedi-GEDI Header 

Content -transfer-encoding: quoted-printable 

<GEDI Header> 




--<unique -boundary 2 > 




Content-type: text/plain 
<human readable GEDI Header> 




--<unique-boundary2>-- 






--<unique-boundaryl> 




Content -type: image/ tiff 

Content-transfer-encoding: base64 

<the document> 






--<unique-boundaryl>-- 



27 



IS 15389 : 2003 
ISO 17933 : 2000 



10.2.3 The Electronic Document Copy Body part(s) — required 

One or more body parts complete the message, transmitting the electronic document copy. 

Either the whole document is .transmitted in a single body part, or the pieces of the document are contained in 
multiple body parts. 

Note that some formats, e.g. multi-page TIFF, have page identification and organization built in, so would not 
require a page per body part approach. 

The Content-Type and Content-Transfer-Encoding will be appropriate for the format of the document, e.g. tiff, jpeg, 
pdf. 

There is no requirement for all pages to have the same Content-Type, although this will probably usually be the 
case. 

EXAMPLE including Human-Readable GEDI Header: 

Content-Type : multipart/gedi-record; 

boundary= " unique-boundaryl " 

--unique-boundaryl 
Content-type: multipart/mixed,- 

boundary="'unique-boundary2" 

- -boundary2 

Content-Type: application/gedi-GEDI Header 

Content-Transfer-Encoding : guoted-printable 

IFID0004GEDIIFVS00033 . 0CILN00042048DFID0008TIFF6 . 0SSAD0005?= ( ) CNSN0006N== 

PICARCNM0008RLG00001SPLN0005N=RLGSVDT001419910802140600TTLE0012PC/Comput= ingAART0013Paul 
SomersonTART0031The DOS you've been waiting forZPADlB60 
- -unique-boundary2 
Content-Type: text/plain 



interchange- format- 
id 
interchange- format- 


GEDI 


3.0 


version 




document- format -id 


TIFF-6.0 


Consumer-name 


PICA 


record-name 


RLGOOOOl 


Supp 1 i e r - name 


RLG 


service-date- time 


1991/08/02 14:06:00 


title 


PC /Computing 


author-of -article 


Paul Somerson 


title-of -article 


The DOS you've been waiting 




for 



--unique-boundary2-~ 
--unique-boundaryl 
Content-Type: image/tiff 
Content-Transfer-Encoding : base64 

<multi~page TIFF image> 
- -unique-boundaryl - - 



10.3 Supporting protocol stack for MIME 



The SI^TP protocol is used for sending. Either St^TP or the P0P3 protocol is used for receiving. These are run 
over TCP/IP. 
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11 Conformance 

11.1 Sending/receiving role(s) 

A system may claim conformance as either 

a) a sending system (Supplier), 

b) a receiving system (Consumer), or 

c) both a sending (Supplier) and receiving (Consumer) system. 

11.2 GEDI Header data element conformance 

A system claiming conformance as a sending system (Supplier) must be able to send all of tKe mandatory data 
elements, as defined in 7.2. This includes all Type 1 data elements, as defined in 7.2.2, since all of these are 
mandatory, and the mandatory Type 2 data elements as defined in 7.2.3. 

A system claiming conformance as a receiving system (Consumer) must be able to receive all of the GEDI Header 
data elements, both mandatory and optional, as defined in clause 8. For extensibility, a receiving system 
(Consumer) must also be able to receive a GEDI Header data element that it does not recognize; the presumption 
is that the system will ignore any unrecognized data elements. 

11.2.1 In order to claim conformance to the GEDI Document Interchange Format Record GEDI-3.0 as a Supplier, 
a system must be able to transmit all of the mandatory GEDI Header elements as defined in this International 

Standard. 

NOTE 1 No ordering of tags is advised, except IFID as the first and ZPAD as the last tag. 
NOTE 2 Tags are not repeatable. 

11.2.2 In order to claim conformance to the GEDI Document Interchange Format Record GEDI-3.0 as a 

Consumer, a system must 

a) be able to receive and process all of the optional elements as defined in this International Standard, and 

b) be able to receive and process TIFF Version 6.0 images, as specified in annex B. 

For purposes of extensibility, a Consumer system must also be able to ignore any unknown elements it receives, 
as long as those elements conform to the structure of <4 character tag><4 character !ength><value> as specified 
in 7.3. 

11.2.3 In order to claim conformance to the GEDI Document Interchange Format Record GEDI-3.0 as a Relay, a 
system must 

a) be able to receive and transmit the GEDI record transparently, without change, and 

b) be able to create and transmit TIFF Version 6.0 images, as specified in annex B. 

1 1 .3 Electronic document copy conformance 

A system claiming conformance as a sending system (Supplier) must be able to send electronic document copies 
in the TIFF image format as defined in annex B.1 . 

A system claiming conformance as a receiving system (Consumer) must be able to receive electronic document 
copies in the TIFF image format as defined in annex B.I . 
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1 1 .4 Protocol conformance 

A system may claim conformance as either: 

a) an FTP system, 

b) a MIME system, or 

c) both an FTP system and MIME system. 

1 1 .4.1 FTP conformance 

A system claiming conformance as an FTP system must be according to clause 9. 

11.4.2 MIME conformance 

A system claiming conformance as a MIME system must be according to clause 10. 
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Annex A 
(informative) 

IVIapping of the ILL-Request APDU to GEDI 



ILL Data Elements 


Components/elements 


GEDI Tag 


Notes 


protocol-version-num 




- 




transaction-id 


initial-requester-id 








-person-or-institution-symbol 


ILTI (S=) 






-nanne-of-person-or-institution 


ILTI (N=) 






transaction-group-qualifier 


ILTI (G=) 






transaction-qualifier 


ILTI (Q=) 






sub-transaction-qualifier 


ILTI (B=) 




service-date-time 


date-time-of-this-service 








-date 


- 






-time 


- 






date-time-of-original-service 








-date 


- 






-time 


- 




requester-id 


person-or-institution-symbol 


RQID 






name-of-person-or-institution 


RQNM (N=) 




responder-id 


person-or-institution-symbol 


RSID 






name-of-person-or-institution 


RSNM (N=) 




transaction-type 




- 




delivery-address 


postal-address 








-rrame-of-person-or-institution 


NPOl 






-extended-postal-delivery-address 


XPDA 


■ 




-street-and-number 


STNM 






-post-office-box 


POBX 






city 


CITY 






region 


REGN 






country 


CNTR 






postal-code 


POCD 






electronic-address 








-telecom-service-identifier 


SYID 






-telecom-service-address 


SYAD 
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ILL Data Elements 


Components/elements 


GEDI Tag 


Notes 


delivery-service 


physical-delivery 

electronic-delivery 
-e-delivery-service 
" e-delivery-mode 
~ e-delivery-parameters 

-document-type 

- document-type-id 
-document-type-parameters 

-e-delivery-details 

-e-delivery-address 
—telecom-service-identifier 

— telecom-service-address 
-e-delivery-id 

— person-or-institution-symbol 

— name-of-person-or-institution 
-name-or-code 
-delivery-lime 


CNSN 
CNSN 


One of e-delivery-address or e- 
delivery-id will be present 


billing-address 


postal-address 

-name 

-extended-postal-delivery-address 

-street-and-number 

-post-office-box 

-city 

-region 

-country 

-postal-code 

electronic-address 
-telecom-service-identifier 
-telecom-service-address. 






ill-service-type 




- 




responder-specific- 
service 




- 
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ILL Data Elements 


Components/elements 


GEDI Tag 


Notes 


requester-optional- 
messages 


can-send-RECEIVED 
requester-CHECK-IN 
can-send-RETURNED 


- 


Not appropriate for transfer to GEDI 
cover but may be used by some 
GEDI applications. 




requester-SHIPPED 


- 






-requires 
-desires 


- 






-neither 


_ 




search type 


level-of-service 


- 






need-before-date 


- 






expiry-flag 
expiry-date 


" 




supply-medium-info- 
type 


supply-medium-type 
medium-characteristics 






place-on-hold 




- 




client-id 


client-name 


CLNT 






client-status 


CLST 






client-identifier 


CLID 




item-id 


item-type 


- 






held-medium-type 


- 






call-number 


CLNO 






author 


ATHR 






title 


TTLE 






subtitle 

sponsoring-body 

place-of-publication 

publisher 

series-title-number 


TTLE 
ATHR 
PLPB 
PUBL 
VLIS 


*Append to title 
*? Append to author 

*Append 




volume-issue 


VLIS 






edition 


EDIT 






publication-date 

publication-date-of-component 

author-of-articie 


PUBD 
PDOC 
AART 






title-of-article 


TART 






pagination 


PGNS & NMPG 






national-bibliography-no 
ISBN 


ISBN 






ISSN 


ISSN 






system-number 
additional-no-letters 


- 


- 




verif ication-ref e rence-sou rce 


- 




supplemental-item- 
description 




■ 
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ILL Data Elements 


Components/elemeitts 


GEDI Tag 


Notes 


cost-info- type 


account-number 

maximum-cost 

reciprocal-agreement 

will-pay-fee 

payment-provided 


- 




copyright-compliance 




CPRT 




third-party-info-type 


permission-to-forward 

permission-to-chain 

permission-to-partition 

permission-to-change-send-to-list 

initial-requester-address 

-telecom-service-identifier 

-telecom-service-address. 

preference 

send-to-list 

-system-id 

~person-or-institution-symbol 

-name-of-person-or-institution 

-account-number 

-system-address 

-telecom-service-identtfier 

-telecom-service-address. 

already-tried-list 

-pe rson-or- institution -symbol 

-name-of-person-or-institution 


- 




retry-flag 








forward-flag 




- 




requester-note 




RSNT 




fora/ard-note 




- 




ill-request-extension 




" 


May need be defined in implementor 
agreements or profiles 
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Annex B 

(informative) 

Electronic Document Copy Format Registrations 



B.I TIFF registration 

B.1.1 General TIFF 

The scanned image of the document will be transmitted in the Tag Image File Format (TIFF) using TIFF Class B. 
All requirements stated in Tag Image File Format Specification Revision 6.0 for Bilevel and Grayscale images 
apply. The entire image is contained in a single, multi-page TIFF file. 

The following values for DFID may be used to identify TIFF: 

TIFF-5.0 
TIFF-6.0 

The following MIME media types will be used to identify TIFF: 



image/TIFF; class=B 
image/TIFF; class=G 



B.I. 2 TIFF Image file GEDl Header 





Tableau 8.1 






Byte 


Description 


WRrrE 


READ 


0-1 


Byte Order 


11 


11 or MM 


2-3 


TIFF 


42 


42 


4-7 


Offset of the ImageFileDirectory 


- 


any 



The following key is used in Tables B.1 to B.5. 

BOLD Field required for all TIFF Classes 

BOLD italic Additional fields required for TIFF 

Half shaded INFORMATIONAL FIELDS 

M Mandatory 

O Optional 

V variable content 

not applicable 
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Table B.2 



TIFF BASELINE 
FIELDS 




GEDI REQUIREMENTS 


Tag 


Type 


Value 


Type 


Value 


Write 


Read 


Artist 


13B.H 


ASCII 




ASCII 


- 


O 


receive 


BitsPerSample 


102.H 


SHORT 


1 


SHORT 


1 


M 


M 


CellLength 


109.H 


SHORT 


- 


SHORT 


- 


7 


7 


CellWidth 


108.H 


SHORT 


- 


SHORT 


- 


7 


7 


ColorMap 


140.H 


SHORT 


- 


SHORT 


- 


7 


7 


Compression 


103.H 


SHORT 


1,2 or 32773 
default=1 


SHORT 


1,2,4 or 
32773^ 


M 


M 


Copyright 


828.H 

8298.. 
H? 


ASCII 




ASCII 


— 


7 


7 


DateTime 


132.H 


ASCII 


- 


ASCII 


- 





receive 


ExtraSamples 


152.H 


SHORT 


0,1 or 2 
defau)t=no field 


SHORT 


7 


7 


7 


FileOrder 


10A.H 


SHORT 


1 or2default=1 


SHORT 


7 


7 


7 


FreeByteCounts 


121.H 


LONG 




LONG 


7 


7 


7 


FreeOffsets 


120.H 


LONG 




LONG 


? 


? 


7 


GrayResponseCurve 


123.H 


SHORT 




SHORT 


? 


? 


7 


Gray ResponseUnit 


122.H 


SHORT 


1...5default=2 


SHORT 


7 


7 


? 


HostComputer 


13C.H 


ASCII 


= 


ASCII 


- 





receive 


ImageDescription 


10E.H 


ASCII 


- 


ASCII 


- 


O 


Teceive 


ImageLength 


101.H 


SHORT, 
LONG" 


V 


SHORT, 
LONG" 


V 


M 


M 


Image Width 


100.H 


SHORT, 
LONG" 


V 


SHORT, 
LONG" 


V 


M 


M 


Make 


10F.H 


ASCII 


- 


ASCII 







receive 


MaxSample 
Value 


119.H 


SHORT 


default=2" 
(BitsPerSample)- 1 


SHORT 


7 


7 


7 


MinSample 
Value 


118.H 


SHORT 


default=0 


SHORT 


7 


7 


7 


Model 


110.H 


ASCII 




ASCII 


7 


O 


receive 


NewSubfile Type 


DFE.H 


LONG 


default=0 


LONG 


yC 


M 


M 


Orientation 


112.H 


SHORT 


l...6default=l 


SHORT 


7 


7 


7 


Photometric 
Interpretation 


106.H 


SHORT 


0...4 


SHORT 


0...4 


M 


M 


PlanarConfiguration 


11C.H 


SHORT 


1 or2default=1 


SHORT 


1 or 2 
defaults 1 


M 


M 


ResolutionUnlt 


128.H 


SHORT 


1..3default=2 


SHORT 


1...3 
default=2 


M 


M 
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Table B.2 (continued) 



TIFF BASELINE 
FIELDS 




GEDI REQUIREMENTS 


Tag 


Type 


Value 


Type 


Value 


Write 


Read 


RowsPerStrip 


116.H 


SHORT, 
LONG<^ 


default=2"32-1 


SHORT, 
LONG" 


? 


M 


M 


SamplesPer 
Pixel 


115.H 


SHORT 


default=1 


SHORT 


default=1 


M 


M 


Software 


131. H 


ASCII 


- 


ASCII 


- 





receive 


StripByte 
counts 


117.H 


SHORT, 
LONG'* 


V 


SHORT, 
LONG" 


V 


M 


M 


StripOffsets 


111.H 


SHORT, 
LONG<^ 


V 


SHORT, 
LONG" 


V 


M 


M 


Subfile Type 
(discontinued) 


OFF.H 


SHORT 


1..3 no default 


SHORT 


? 


DONT 
USE 


? 


Ttiresholdtng 


107.H 


SHORT 


1..3default=1 


SHORT 


7 


? 


? 


XResolution 


11A.H 


RATIONAL 


V 


RATION 
AL 


V 


M 


M 


YResolution 


11B.H 


RATIONAL 


V 


RATION 
AL 


V 


M 


M 


^ values of Compression field 

1 = no compression 

2 = CCITT Group 3 1 -Dimensional Modified Huffman ru 
4 = Facsimile-compatible CCITT Group 4 

32773 = PackBits 

•^ LONG preferred 

■^ values of NewSubfiled Type field 
BitO 
Bitl 
Bit 2 

=* SHORT preferred 


n lengtti encoding 
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Table B.3 



TIFF BILEVEL IMAGE 
Required FIELDS 


REQUIREMENTS FOR BILEVEL IMAGES 


GEDI REQUIREMENTS 


Tag 


Type 


Value 


Type 


Value 


Write 


Read 


Compression 


103.H 


SHORT 


1,2 or 
32773 
default=1 


SHORT 


1,2,4 or 
32773^ 


M 


M 


ImageLength 


101.H 


SHORT, 
LONG^ 


V 


SHORT.LONG" 


V 


M 


M 


ImageWidth 


100.H 


SHORT, 
LONQb 


V 


SHORT.LONG'' 


V 


M 


M 


Photometric 
Interpretation 


106.H 


SHORT 


0...4 


SHORT 


0...4 


M 


M 


RowsPerStrip 


116.H 


SHORT, 
LONC^ 


default=2* 

*32-1 


SHORT,LONG<: 


V 


M 


M 


StripBytecounts 


117.H 


SHORT, 
LONG= 


V 


SHORT,LONG= 


V 


M 


M 


StripOffsets 


111.H 


SHORT, 
LONG= 


V 


SHORT,LONG'' 


V 


M 


M 


XResolutlon 


11A.H 


RATIONAL 


V 


RATIONAL 


V 


M 


M 


YResolution 


11B.H 


RATIONAL 


V 


RATIONAL 


V 


M 


M 


NOTE The Consumer application must be able to receive these fields, but it is permissible to discard the values 
received. 


* values of Compression field 

1 = no compression 

2 = CCITT Group 3 1-Dimensional Modified Huffman run lengtfi encoding 
4 = Facsimile-compatible CCITT Group 4 

32773= PackBits 

^ LONG preferred 
<= SHORT preferred 



Table B.4 



TIFF FACSIMILE 
FIELDS 


CLASS B REQUIREMENTS FOR CCITT 
BILEVEL ENCODINGS 


GEDI REQUIREMENTS 


Tag 


Type 


Value 


Type 


Value 


V\;rile 


Read 


Compression 


103.H 


SHORT 


3or4 


SHORT 


1,2,4 or 
32773^ 


M 


M 


T40ptions (CCITT 
Group 3) 


1Z4.H 


LONG 


default=0 


do not write these fields; be prepared to receive them; 
it is permissible to discard the values received 


TeOptions (CCITT 
Group 4) 


125.H 


LONG 


default=0 


^ values of Compression field 

1 = no compression 

2 =■ CCITT Group 3 1 -Dimensional Modified Huffman run 
4 = Facsimile-compatible CCITT Group 4 

32773 = PackBits 


ength encoding 
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Table B.5 



TIFF DOCUMENT 
STORAGE AND 
RETRIEVAL FIELDS 


REQUIREMENTS FOR STORAGE 
AND RETRIEVAL 


GEDI REQUIREMENTS 


Tag 


Type 


Value 


Type 


Value 


Write 


Read 


DocumentName 


10D.H 


ASCII 




ASCII 




O 


receive 


PageName 


11D.H 


ASCII 




ASCII 







receive 


PageNumber* 


129.H 


SHORT, 
SHORT 


V 


SHORT, 
SHORT 


V 


O 


receive 


XResolution 


11A.H 


RATIONAL 


V 


RATIONAL 


V 


M 


receive 


YResolution 


11B.H 


RATIONAL 


V 


RATIONAL 


V 


M 


receive 


NOTE The Consumer application must be able to receive these fields, but it is permissible to discard the values 
received. 


^ This tiald is used to specify page numbers of a multiple-page document (e.g. facsimile). PageNumber[0] is the page number; PageNumber[1] is the 
total number of pages in the document. If PageNumber[1] is 0, the total number of pages in the document is not available. The first page is numbered 0. 



B.I .3 TIFF compression algorithms 

GEDI will support the following compression algorithms, as specified in the Tag Image File Format Specification, 
Revision 6.0. 

Table B.6 



COMPRESSION ALGORITHM 


VALUE 


WRITE 


READ 


no compression 


1 


optional 


mandatory 


CCITT Group 3 1 -Dimensional Modified 
Huffman run length encoding' 


2 


optional 


optional 


Facsimile-compatible CCITT Group 4 


4 


optional 


mandatory 


PackBits 


32773 


optional 


mandatory 



CCITT Group 3 1 -Dimensional Modified Huffman run length encoding is included for compatibility with TIFF 
CLASS B 



B.2 PDF registration 

The specification of PDF is available in the Portable Document Format Reference Manual Version 1.3, Adobe 
Systems incorporated, March 11, 1999. 

The specification is copyrighted by Adobe Systems Inc. 

Note that GEDI does not specify how a PDF files is created, nor which Adobe Acrobat product is used to view and 
print PDF documents. 

PDF is registered by lANA as a MIME body part. The registration is available at: 
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IS 15389 : 2003 
ISO 17933 : 2000 

ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/pdf 
The following value for DFID may be used to identify PDF: 

PDF 
The following MIME media type will be used to identify PDF: 

application/pdf 

B.3 JFIF/JPEG registration 

In addition to TIFF, GEDI recognizes JFIF (JPEG File Interchange Format), a "low-end' format that transports 
pixels. JFIF is what is most commonly meant by references to a "JPEG file." This format is usually supported by 
WWW browsers. This is not to be confused with TIFF/JPEG, which is not included in the GEDI specification. 

Information about JFIF can be found at: 

www.cis.ohio-state.edu/hypertext/faq/usenet/jpet-faq/part1/faq-doc-14.html 
The following values for DFID may be used to identify JFIF/JPEG: 

JFIF 
The following MIME media type will be used to identify JFIF/JPEG: 

JPEG 
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IS 15389 : 2003 
ISO 17933 : 2000 
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( Continued from second cover) 

In this adopted standard, reference has also been made to the following document for which there is 
no Indian Standard: 

Document No. Description 

RFC 959 File Transfer Protocol ( FTP ), October 1 985 

The Sectional Committee responsible for the preparation of this standard has reviewed the provisbns 
of the above referred International Standards/document, and has decided that they are acceptable tor 
use in conjunction with this standard. 

Annexes A and B of this Indian Standard are for Information only and do not form a part of the standard. 



Bureau of Indian Standards 

BIS is a statutory institution established under the Bureau of Indian Standards Act, 1986 to promote 
harmonious development of the activities of standardization, marking and quality certification of goods and 
attending to connected matters in the country. 

Copyright 

B IS has the copyright of all its publications. No part of these publications maybe reproduced in any form without 
the prior permission in writing of BIS. This does not preclude the free use, in the course of implementing the 
standard, of necessary details, such as symbols and sizes, type or grade designations. Enquiries relating to 
copyright be addressed to the Director (Publications), BIS. 

Review of Indian Standards 

Amendments are issued to standards as the need arises on the basis of comments. Standards are also reviewed 
periodically; a standard along with amendments is reaffirmed when such review indicates that ho changes are 
needed; if the review indicates that changes are needed, it is taken up for revision. Users of Indian Standards 
should ascertain that they are in possession of the latest amendments or edition by referring to the latest issue 
of "BIS Catalogue' and 'Standards : Monthly Additions'. 

This Indian Standard has been developed from Doc : No. MSD 5 ( 236 ). 

Amendments Issued Since Publication 

- — -' 

Amend No. Date of Issue Text Affected 
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